Please separate this PR into one for the bug fix and another.

Please separate this PR into one for the bug fix and another.

#354 ✅. I was debating splitting it in the first place but I only discovered the bug because of an extra test I added to this PR. So #354 should be merged first, then I can update/finalize this PR with the extra getter-on-IUO fixture.

Rebased on master now that #354 has landed, and re-added the promised getter-on-IUO edge-case fixture as a separate commit: getterHistoryEdgeTypes now includes an Int! property, whose tracked getter renders a valid Int! backing store (previously this produced the Int?! that #354 fixed).

While re-testing with Fable 5, 'we' also hardened coverage with three more compiled fixtures: getter: all = false overriding --enable-getter-history (as the README promises), a tracked getter on an associatedtype property, and a test locking that inherited members follow the declaring protocol's annotation (same semantics as history:/rx:/combine:).

I’m afraid I cannot accept this proposal.
We want to avoid adding more generation patterns to the codebase.
Personally, I can't think of a scenario where testing a getter's callCount is necessary, and I believe this is the first time this feature has been requested in mockolo's long history.
Since this seems to be a very specific edge case, I would recommend writing a custom mock class manually just for that specific scenario.

@sidepelican Thank you so much for merging the other PRs and taking the time to review this one as well. Let me try to convince you anyway.

First, it'd be fully opt-in via annotation (or the flag), mocks that don't request it are byte-for-byte unchanged, no default-behavior change.

Second, a structural point worth naming: mockolo currently supports the setter call-count tracking (...SetCallCount / --allow-set-call-count). So this PR wouldn't add a new pattern, it'd just complete an existing one, the read-side mirror of it.

Third, I'd mostly agree with you that the "was this read?" assertions are usually redundant with the outcome but IMHO not always.

Three categories the outcome genuinely can't capture:

1. A read that must not happen: "short-circuit" paths:

final class LoginViewModel {
    private let interactor: AuthInteracting   // var authType / var isBiometricEnabled { get }

    func onViewAppeared() {
        guard interactor.authType == .biometric else { return }   // PIN -> return before touching biometrics
        if interactor.isBiometricEnabled {                        // isBiometricEnabled backed by LAContext / Keychain
            coordinator.promptForBiometrics()
        }
    }
}

---

// SwiftyMocky test for the PIN path:
Given(interactor, .authType(getter: .pin))
// mockolo: interactor.authType = .pin
sut.onViewAppeared()
Verify(interactor, .never, .isBiometricEnabled)   // proves we short-circuited
// mockolo: #expect(interactor.isBiometricEnabledGetCallCount == 0)

2. A read that must happen exactly once

func configure(_ rows: [Transaction]) {
    let formatter = settings.currencyFormatter            // built once, reused for every row
    cells = rows.map { Cell(amount: formatter.string(from: $0.amount)) }
}

---

// rebuilding a NumberFormatter per row is the expensive part — output is identical either way
Verify(settings, .once, .currencyFormatter)
// mockolo: #expect(settings.currencyFormatterGetCallCount == 1)

3. A read that must happen exactly n times

func send(_ request: Request, retries: Int) {
    for _ in 0...retries {
        var attempt = request
        attempt.token = session.accessToken          // re-read each attempt — token may have refreshed after a 401
        if transport.send(attempt).isSuccess { return }
    }
}

---

// 1 initial try + 2 retries
Verify(session, 3, .accessToken)   // re-read every attempt, not hoisted/cached once
// mockolo: #expect(session.accessTokenGetCallCount == 3)

Either way, thanks again to you and Uber for maintaining this project, it's saved me a ton of hand-written mocks, I really love mockolo.

I understand that you prefer writing getters with side effects.
Personally, I think such code undesirable, and adding GetCallCount would actually make writing such code easier-effectively justifying its implementation.
Considering Swift's culture, I felt this feature shouldn't be included.